Method and device for analyzing an information sytem security

ABSTRACT

There is proposed a method for analyzing the security of an information system comprising a modeling phase, including modeling of the information system, and a simulating phase, including specification and simulation of potential attack against the information system.

The present invention pertains to the field of tools for analyzing andcontrolling information systems security (ISS).

Structured-design tools (such as SADT or SART) of an information systemtake no account of the security of the system. Generalist risk analysisprocedures (such as Marion, Melisa or CRAMM) are imprecise, andincapable of revealing the technical flaws of a system. Operationaldependability tools (SDF) are limited to the problems of reliability andavailability, but take no account of malice. Intrusion detection systems(IDS) and vulnerability analyzers operate only on real systems, arespecific to a restricted domain, and have only a partial picture ofsecurity. Security strategy editors operate from the viewpoint of thedefender only, and comprise no function for analyzing the consistency ofsecurity, nor for searching for possible flaws and attacks.

The invention is directed at a method and a device for analyzing thesecurity of information systems which relies on the modeling andsimulation of the system and of possible attacks, so as to analyze andcontrol the security of the system.

More particularly, a first aspect of the invention relates to a methodfor analyzing the security of an information system comprising:

-   -   a modeling phase, comprising the modeling of the information        system, and    -   a simulation phase, comprising the specification and the        simulation of potential attacks against the information system.

The modeling phase comprises the specification of the architecture ofthe system with a set of components of the system and relations betweensaid components, that is to say according to a components/relationsmodel.

Preferably, determined states are associated with each component of theinformation system, each state being able to take a sound value and oneor more unsound values. Certain at least of said states pertainrespectively to the activity, the confidentiality, the integrity and/orthe availability of the component with which they are associated.

Preferably, the modeling phase further comprises the specification of aset of behavioral rules, in particular from the system operationstandpoint and from the security standpoint (protection rules),associated with the components of the system.

According to an advantage of the invention, the user can adopt theviewpoint of the defender during the modeling phase, and the viewpointof the attacker during the simulation phase. By iterating alternatemodeling phases and simulation phases, he succeeds in controlling thesecurity of the information system.

According to another advantage, the invention makes it possible toanalyze the security of an information system without interveningdirectly on the latter. Specifically, the launching of the attacks iseffected on a virtual system, corresponding to the real system modeled.

Advantageously, the analysis of the security may take place very earlyin the information system design process, and in particular before itsphysical deployment.

The method makes it possible to model an information system, whilerestricting oneself to its security aspects, and hence while remainingcontrollable by a human person, by virtue of simplifying concepts andprinciples. The invention makes it possible to handle in a genericmanner in particular the technical aspects (that is to say those relatedto the technical characteristics of the information system), human,procedural and physical aspects (for example geographical aspects). Agood compromise between realism and simplicity of modeling allows a user(typically the designer or the administrator of the information system,or a security technical auditor) to model the information system withouthaving to reproduce it completely.

The method also makes it possible to realistically simulate all attacksknown within the world of information systems. These attacks turn out tobe generic, and may apply to fields connected with information systems(physical security for example).

Finally, it makes it possible to realistically simulate all the parriesknown within the world of information systems, be they for prevention orfor detection. The modeling of prevention parries is carried out bysecurity rules. The modeling of detection parries is carried out bymeans of metrics.

To summarize, the method makes it possible to quickly analyze thefeasibility of a very large number of attacks on a given system. Withlittle experience, the user can simulate around 100 to 200 elementaryattacks per day, this being considerably more than what could be done ona real system.

A second aspect of the invention relates to a device for theimplementation of a method according to the first aspect. For thispurpose, the device advantageously comprises a man/machine interface forthe implementation of the modeling phase and/or an attacks/parriesengine for the implementation of the simulation phase.

Advantageously, the man/machine interface exhibits a functionality ofmultiview display of the system modeled.

Preferably, the man/machine interface makes it possible to display thesystem modeled according to a components/relations model.

The device is intended to be used as a technical audit tool for thesecurity of existing information systems (that is to say those alreadydeployed), for which it has the advantage of not disturbing them duringtheir utilization. It may in particular analyze destructive attackswithout affecting the real system.

The device can also be used as a tool for aiding the design of thesecurity of systems currently under design or production, thereby makingit possible to tailor and test their protection policy even before theirinstallation.

It may also be used as a favored tool for system certification, in thesense of security certification according to the existingstandardization: TCSEC, ITSEC (“Information Technology SecurityEvaluation Criteria”) and CC (“Common Criteria”). This standardizationin fact currently makes it possible to certify products with sharplydelimited contours, but has hitherto been inapplicable to systems. Thelatter are in fact too vast, complex, heterogeneous, have contours thatare poorly defined and changeable, to be evaluated with the techniquesfor evaluating products.

To summarize, the device is a tool intended for security specialists:system administrators, security technical auditors. To such people itaffords in addition the possibility of adopting the viewpoint of theattacker, which viewpoint is absolutely necessary for constructingeffective and suitable protection.

Other characteristics and advantages of the invention will becomefurther apparent on reading the description which follows. The latter ispurely illustrative and should be read in conjunction with the appendeddrawings in which:

FIG. 1 is a chart illustrating the modeling and simulation phasesaccording to the method of the invention;

FIG. 2 is a schematic diagram illustrating the elements of a deviceaccording to the invention;

FIG. 3 is a diagram illustrating the construction of acomponents/relations model for an information system;

FIG. 4 is a diagram showing an exemplary components/relations model, inwhich appear relations of hosting and relations of exchange betweencomponents;

FIG. 5 is a diagram illustrating examples of service relations betweencomponents of an information system modeled according to the invention;

FIG. 6 is a diagram which illustrates a detailed example of thesimulation phase of the method according to the invention;

FIGS. 7 a to 7 e are diagrams which illustrate examples of attack paths;

FIG. 8 is a diagram showing the transmission of an attack through anattack path in a modeled information system;

FIG. 9 and FIG. 10 are diagrams presenting a mechanism of upstream anddownstream stacks;

FIG. 11 is a diagram illustrating an example of the operation of theupstream and downstream stacks;

FIG. 12 is a chart illustrating the general operating algorithm of theattacks/parries engine;

FIG. 13 is a chart which illustrates a mechanism for applying protectionrules;

FIGS. 14 a and 14 b are charts illustrating a functional routingmechanism and a states contagion mechanism, respectively;

FIG. 15 is a diagram illustrating diversion techniques in a modeledinformation system;

FIG. 16 is a diagram illustrating the displaying of a modeled system,with a multiview functionality;

FIG. 17 is a diagram illustrating the multiview display according to ahierarchical approach; and

FIG. 18 is a schematic diagram of a device according to the invention.

As illustrated by the graph of FIG. 1, the method comprises two usagephases, themselves decomposed into two steps.

During a modeling phase, the user adopts the viewpoint of the defender.The modeling phase comprises a step 1 of specifying the architecture ofthe system with a set of components of the system and relations betweensaid components, which comprise propagation relations and servicerelations. Step 1 culminates in a modeled architecture, hereinaftercalled the components/relations model, of the real system, this modelbeing saved in the form of a file in a memory 11. This model may berepresented graphically by a graph comprising boxes symbolizing thecomponents, connected by arrows symbolizing the relations. The modelingphase also comprises a step 2 of specifying behavioral rules, not to beconfused with the aforesaid relations. These behavioral rules define themanner of operation of each component, from the operational and securitystandpoints, in particular the protections that it provides. Step 2culminates in the construction of a file of behavioral rules, which issaved in a memory 12.

Conversely, during a simulation phase, the user adopts the viewpoint ofthe attacker. The simulation phase comprises a step 3 of specifying theattacks, which culminates in the creation of one or more attackscenarios. These scenarios are saved in the form of files in a memory13. The simulation phase also comprises a step 4 of interactivesimulation of attacks. This simulation is carried out by anattacks/parries engine. It culminates in the creation of a journal ofthe attacks, which is saved in the form of a file in a memory 14.

The files saved in the memories 11, 12, 13 and 14 may be imported fromor exported to various applications, so that their reuse is possible.

The modeling phase 10 and simulation phase 20 may be alternatelyiterated, each time modifying all or part of the parameters(components/relations model, behavioral rules, attacks) taken intoaccount. This allows good control of the security of the system by theuser.

In the subsequent description, there is described a mode ofimplementation of steps 1 to 4 of the method, with however a modifiedpresentation as to the order of the steps. Specifically, step 3(specification of attacks) and step 4 (interactive simulation byattacks/parries engine) are set out before step 2 (parametrization ofthe protection rules), so as to aid the comprehension of the text.Furthermore, the description of these steps is supplemented with apresentation of two complementary mechanisms: the metrics and theman/machine interface (MMI).

Firstly, the main elements of a device according to the invention arepresented with reference to the functional chart of FIG. 2. In thisfigure are represented at the top a group 20 a of the elements usedduring the modeling phase, and at the bottom a group 20 b of those usedduring the simulation phase. Moreover, a man/machine interface 15 isrepresented on the right.

The group 20 a comprises a language of rules 21 making it possible toformulate the protection rules 22, a set of basic metrics 23, and thecomponents/relations model 24.

The group 20 b comprises a language of attacks 25 making it possible toformulate the attack scenarios 26, the attacks/parries engine 16, anupstream and downstream stacks mechanism 27, a set of potential states28 and calculated metrics 29.

In FIG. 2, the solid line arrows symbolize the transfers of informationbetween the elements, and the broken lines symbolize the functionallinks between the elements. The role of each of these elements willbecome apparent in what follows.

The first step of the method, step 1, consists in constructing thecomponents/relations model (or architecture) of the real system via thehuman interface 15. To do this, the system is decomposed into elementarycomponents (or atoms), endowed with attributes, and connected byrelations.

The steps of the construction of the components/relations model areillustrated by the graph of FIG. 3.

A first step 31, the user puts into place on a two-dimensional graph thecomponents which form the system. In an example, each component isrepresented by a rectangle containing its four potential states and itsname.

The components may represent all kinds of heterogeneous real objects ofphysical type (site, building, storey, premises, strongrooms, door,window, lock, key, etc.), a medium (paper, fixed disk, diskette, CD Rom,magnetic tape, etc.), a network (electrical, computing, telephonic, RF,aerial, etc.), hardware (mechanical, network, computing, station,server, screen, keyboard, printer, etc.), software (OS, driver,application, service, etc.), data (directory, file, information,database, password, etc.), people (user, assailant, director,administrator, organization, service, etc.), and so on. This indicativelist is nonlimiting.

Each component has several attributes, which are defined in a step 32.The attributes comprise static attributes and dynamic attributes. Thestatic attributes comprise for example a name (composed of a nature andof an identifier), and possibly one or more adjectives. The dynamicattributes comprise for example potential states referred to as “ACID”states (see later), an alleged name (in the case where the component isa usurper), and a link to a usurper component (in the case where thecomponent is usurped).

The adjectives are intended to make it possible to designate componentswithout naming them, and to do so either in rules (for example: accessis denied to all the “external” components), or in attacks (for example:discover all the “IP” components). The list of adjectives is open, anddefined by the user during modeling. An example of adjectives classed byutility is given by table I hereinbelow: TABLE I Utility AdjectivesMembership Internal, external, private, public, establishment, group,central, local, remote Sensitivity, gravity Normal, important, critical,vital, rights reserved (DR), confidential defense (CD), secret defense(SD), top secret defense (TSD), tactical, strategic Access entitlement,User, author, reader, editor, technical or technician, operator,utilizer, organizational role, administrator, trainee, employee,internal or external guard, supervisor, manager, boss, director, client,partner, consultant, supplier, client, competitor Trusted or untrustedReliable, loyal, sincere, serious, known, unknown, dubious, suspect,hacker Technique IP, network, computing, OS, executable, information,fixed, mobile Protection Encrypted, hidden, backed-up, catalogued,administered, duplicated

Modeling is a complex task for the user. This is why the modelingmechanisms are designed to operate even on a model that is not fullycompleted, hence may possibly be partially inconsistent. This allows theuser to work according to a progressive and iterative process,alternating the modeling and the tests of operation by simulation.

The components are ubiquitous and timeless. The aim of this principle isto simplify the modeling work, without being detrimental to realism,insofar as the topic is security. It is manifested concretely by thefact that a component may be, in particular:

-   -   multiple, that is to say represent several similar real objects        situated at several places;    -   dispersed, that is to say represent an object of large size not        situated in a precise zone (for example a network);    -   partial, that is to say represent a part of a complex real        object;    -   replicated, when two components can represent the same real        object (for convenience of modeling);    -   duplicated, when, for example, a first real file exhibits        several copies on several media;    -   temporary, that is to say represent for example an intermittent        telephonic communication; and    -   mobile: for example, a portable station, or a person are mobile        (“nomadic”) by nature.

Propagation relations associated with the components are defined in astep 33. These relations are bidirectional, and able to convey attacksin both directions. They may be of two distinct types: of hosting type(capacity, supply) and of exchange type.

The diagram of FIG. 4 illustrates an example of hosting relations(symbolized by vertical arrows) between a client software 41, aworkstation 42 (a personal computer or PC) in which said client softwareis saved, and an office 43 in which said workstation is situated. Thesame diagram also illustrates exchange relations between the clientsoftware 41 and a server software 44 with which the client softwareexchanges data, between the workstation 42 and a computing network towhich the workstation is linked 45, and between the office 43 and acorridor 46 allowing access to said office.

When a component is traversed by an attack, it may or may not leave atrace of the passage in the attack. For example, a postal package bearsthe postmark of the issuing post office, but not of the receiving postoffice. Likewise, an IP (“Internet Protocol”) packet contains orotherwise the IP address of a router traversed.

To take account of this reality, each component, for each of therelations which it receives, has an indicator of transparency oropacity. If it is transparent, it will not be seen from the componentsdownstream in the path of the attack, and these components will nottherefore be able to take account thereof in their protection rules. Ifconversely it is opaque, the downstream components will see it, but itwill hide the upstream components of the same type (that is to sayhaving the same adjectives).

Alongside the propagation relations, provision is also made for servicerelations, which are defined in a step 34. The service relations areunidirectional, and do not convey attacks. Their aim is to make itpossible to designate a component on the basis of another, in the formof an indexation.

The diagram of FIG. 5 illustrates an exemplary service relation. In thisfigure are represented a workstation 51, a person 52, a password 53 andan office 54. Propagation relations between these components aresymbolized by continuous lines, and service relations are symbolized bydiscontinuous lines of which it is composed. In this example, thecomponent “password” 53 may be designated by the formula “pass(person)”.Likewise, the component “office B24” may be designated by“office(person)”.

Returning to FIG. 3, it will be noted that steps 31 to 34 may beiterated so as to allow the user to refine the construction of thecomponents/relations model.

When the components/relations model is completed, a routing table isconstructed in a step 35. This table is calculated automaticallyaccording to the principle of the shortest path between the components,using the propagation relations alone. The result is for example a startcomponent/finish component matrix.

The temporal profile of each component is stored by means of fourpotential states, called “ACID” states (A=activity, C=confidentiality,I=integrity, D=availability). These states correspond to the three knowndomains of security (C, I, D), to which has been added the state “A” for“activity”. The latter state represents the ability of a component toact, either in a normal manner (licit), or in a malicious manner, thisbeing under the influence of the assailant.

It will be noted that these states ACID correspond substantially to theelementary rights of the security models: “XRWD” (X=execute, R=read,W=write, D=delete). They are independent of one another.

In an example each state has four possible values: normal, weakened,degraded, dangerous. In an example, these values are coded on thecomponents/relations graph by a color code (for example green, yellow,red, dark blue, respectively), used for filling in the rectanglesymbolizing each component.

Table II hereinbelow gives the meaning of the four possible values ofthe four potential ACID states. TABLE II ACID states: ActivityConfidentiality Integrity Availability Sound closed discreet intactavailable Weakened open discovered usurper saturated Degraded activedivulged altered blocked Dangerous interactive betrayed corrupteddestroyed

The aim of the analysis is to study the possibility of effecting anintrusion into a system. Insofar as it is necessary to makesimplifications with respect to reality, it is preferable to simplify inthe direction of pessimism, doing so with the aim of security. Statedotherwise, the device may see intrusions where there are none, but mustnot forget intrusions that are actually possible. The user will thentake things in his stride, if necessary.

This principle, the so-called “worst case policy” is applied in theattacks/parries engine in the following manner.

At the start of the modeling, the four potential states of eachcomponent are respectively initialized to the value “sound”. The usercan initialize them manually to a different value if he so wishes. Thestates may then evolve only toward degradation, as and when the attackssucceed.

The states are “potential”, that is to say they signify that thecomponents “may” be in the states indicated, but not necessarily. Thisimplies that two apparently incompatible states (for example, acomponent which is both “active” and “destroyed”) can coexist. When twostates are incompatible or inconsistent, the device chooses thesituation which is most unfavorable to the defender.

When a (modeled) component represents several real objects, itspotential states are those of the most degraded real object.

Finally, the test of a state of a component in a rule does notcorrespond to a relation of equality, but to an order relation. Forexample, the test “component=blocked” is positive if the component iseither “blocked”, or “destroyed”.

An exemplary implementation of step 3 and of step 4 of the method,namely the specification of the attack scenarios and their interactivesimulation, will now be described. For this purpose, reference is madeto the chart of FIG. 6.

In a step 61, an attack is defined. In an example, an attack isenvisaged for each degradation of an ACID state. The correspondingattacks are called elementary attacks hereinafter. They are linkeddirectly to the ACID states. For example, to cause a component to passto the “blocked” state, the “block” attack is used.

There are therefore twelve elementary attacks (corresponding to thetwelve unsound values of potential states), which are summarized intable III hereinbelow, plus a special attack referred to as a usurpingattack. The latter attack, called “ChangeNameAlleged”, allows acomponent to usurp the name of another. Usurping is in fact afundamental technique of intrusion. TABLE III ACID attacks ActivityConfidentiality Integrity Availability weak open discover usurp saturateserious activate spy alter block dangerous penetrate betray corruptdestroy

When defining an elementary attack, the user (who takes up thestandpoint of the attacker) enters the following parameters:

-   -   type of attack, out of the 13 hereinabove;    -   type of protocol (see hereinbelow); and,    -   elements of the path (see later).

The “protocol” generalizes the concept of telecommunication protocol,and designates any means of transmitting an attack between twocomponents. An attack is always made concrete by the transmission in thesystem of a real, physical or logical, object conveying maliciousinformation, software or mechanisms.

The list of protocols is open, the user being able to define as many ofthem as he wishes during modeling. Examples of protocols are:

-   -   physical protocols: letter, parcel, diskette, CD Rom, person,        etc.    -   logic and computing protocols: mail, web, file, Telnet, Netbios,        TCP/IP, FTP, SSL, etc.    -   specialized protocols: missile, RF wave, laser, etc.    -   etc.

The attack language uses the same words as the rules language, and makesit possible to define complex attack scenarios. An elementary attackline is for example:“start=assailant+intermediate=Internet+protocol=mail+finish=user+attack=destroy+target=station(user)”

In English, this attack line signifies that the assailant isdispatching, via the Internet, an email to the user, containing a logicbomb which will destroy his station.

The attack path is one of the central concepts of the device, the objectof which is precisely to find attack paths in a modeled system. Duringsimulation, the user specifies the path in the following form:

-   -   a start component;    -   a finish component;    -   a target component; and, possibly    -   an intermediate component.

The assailant and the target must necessarily be on the path, but notnecessarily at the beginning or at the end. The diagram of FIGS. 7 a to7 e show various possibilities (nonlimiting) of the attack path, whichmay each correspond to a real case. For example, when the target is aworkstation:

-   -   in FIG. 7 a, the assailant saturates the workstation with        artificial traffic transmitted via the network;    -   in FIG. 7 b, the assailant dispatches a virus by email which is        executed by a “pigeon” user, thereby altering the workstation;    -   in FIG. 7 c, the assailant is a hacker server, and it is a        “pigeon” user that consults a web page on a hacker server and        receives a hacker Java applet which alters the station;    -   in FIG. 7 d, the assailant is also a hacker server and the        workstation (rendered active) opens a “reverse backdoor” to the        hacker server; and,    -   in FIG. 7 e, the assailant is an altered network through which a        session passes, thus disclosing information of the workstation.

Of course, the examples above are illustrative and in no way limiting.

Returning to FIG. 6, the attack specified in step 61 is launched in astep 62. In a step 63, it is executed by the attacks/parries engine. Andin a last step 64, the result of the attack is noted. Steps 61 to 64 areiterated, being executed for each attack of the scenario of attacks.

The result of an attack, if it succeeds, is to cause one of the ACIDstates of the target component to pass to a degraded value (unsound), orto a more serious degraded value if it was already at a degraded value.For example in the case of the “block” attack:

-   -   if the component is less degraded than “blocked” (for example,        “saturated”), then it becomes “blocked”;    -   if it is already “blocked”, then it remains “blocked”; and,    -   if it is more degraded than “blocked” (for example “destroyed”),        then it does not change state.

The manner of operation of the attacks/parries engine will now bedescribed in greater detail. Typically, the transmission of an attackover the attack path is effected according to three successive phases,illustrated by the diagram of FIG. 8, namely:

-   -   a propagation phase during which the attack traverses the vector        components, which may or may not provide the security filtering        via their protection rules;    -   an absorption phase during which the attack may or may not        degrade the target, depending on its own defenses (protection        rules); and,    -   a contagion phase during which the degradation of the target may        be communicated to other components without them being able to        defend themselves (for example, the explosion of an office        brings about the destruction of the equipment present in this        office).

When an attack arrives in a component, the attacks/parries engineperforms therefor a certain number of checks (rules), based on thestates of certain components, and in particular on the componentssituated upstream and downstream in the path of the attack. For theselatter components, represented in the diagram of FIG. 9, the informationavailable to the attacks/parries engine is consigned respectively to theupstream stack and to the downstream stack which were presented earlierwith regard to the diagram of FIG. 2. These upstream and downstreamstacks are the modeling of the indications borne on the real objects(for example addresses and postmarks on a parcel, IP addresses on an IPpacket, etc.).

The upstream stack gives the list (in order) of all the componentsalready traversed by the attack. In an example, there are precisely twoupstream stacks: the one which contains the exhaustive list of all thecomponents, together with their real name, and the other which containsonly the list of opaque components, together with their alleged name.The first list is used to execute the component's possibility andcontagion rules. The other is used to execute in respect of theprotection rules (identification, authorization and routing).

The downstream stack gives the list of identified destinations of theattack. There is a final destination, and possibly one or moreintermediate destinations. These intermediate destinations arespecified, either by the user during the definition of an attack, or bythe functional routing. The downstream stack is used by the rules of thecomponents.

In the example illustrated in FIG. 10, the router 111 and the Internet112 are transparent (since the source IP address of the IP packetscoming from outside is unchanged). This is why, being stacked in thefirst upstream stack 110 of real names, and they are not stacked in thesecond upstream stack 120 of visible names (that is to say real oralleged, as the case may be). Additionally, the hacker 113 usurps thename of a user 114. His “visible name” (stacked in the second upstreamstack 120) is therefore “user” and not “hacker”. The downstream stack isdesignated by the reference 130.

For each transit of an attack, the engine performs the following threeoperations:

-   -   firstly, it determines the next destination component of the        attack: this is the first component of the downstream stack,    -   secondly, it determines, by virtue of the local routing matrix,        which relation is the one to be adopted to go to this component;        and,    -   thirdly, the component which lies on the other side of the        relation becomes the current component.

The attack stops when the downstream stack is empty (and not when thefinish component is reached, since other components may be stackeddownstream after the finish).

For the current component (reached through the attack), the engineperforms the following operations, illustrated by the diagram of FIG.11:

-   -   it extracts the current component from the downstream stack, if        it is there (step 1);    -   it tests the component's propagation rules, which may accept or        deny the attack;    -   if the attack is denied, the engine stops it, otherwise it        continues the following actions,    -   within the framework of the functional routing rules, it can        stack an intermediate component downstream (step 2);    -   it stacks the current component in the upstream stack (step 3);        and    -   if the attack is accepted, it routes it to the next component.

The general algorithm for the operation of the attacks/parries engine isgiven by the chart of FIG. 12.

In this chart, the keyword “me” designates the current component. Totransport or absorb an attack, the current component must be in the“open” state (state A of the ACID states). To absorb the attack, thetarget component must be found in the first upstream stack, that of thereal names. It will be noted that the identification and authorizationrules always give “yes” as a result if the component is corrupted.

In FIG. 12, the three phases of the transmission of the attack, namelypropagation, absorption and contagion of the attack, are representedseparately.

Step 2 of the method, which is the parametrization of the rules forprotecting the components, will now be described.

When the architecture of a system is specified (at the end of step 1),this architecture being represented by the components/relations graph,then the behavior of the components still has to be described, from theoperational and security standpoints.

For this purpose, step 2 consists in parametrizing the operation of eachcomponent, and in particular in describing the protections that itaffords. This is done by means of the entry of rules, structuredaccording to a language and a grammar of rules.

The rules language is characterized by, its capacity for realism (toprecisely describe the manner of operation of a real component),ergonomics for the user (simplicity, flexibility, naturalness, fewspecial signs) and genericness (that is to say the fact that it allowseasy reuse of the rules from one model to the other).

From the editing standpoint, the language is preferably in the form ofASCII or XML text, is readable, modifiable and printable with aconventional text processor (such as Notepad, MS-Office), acceptsnatural language comments in the form: /* comment */, accepts uppercase/lower case and accents (but which are not discriminating), and usesthe characters “blank” and “next line” for presentation only.

Preferably, the words of the language appear in the same manner and inthe same form in the graphical representation of thecomponents/relations model, in the specification of the rules (ruleslanguage), in the specification of the attacks (attacks language), andin the journal of attacks.

The language is chiefly a predicates language (or logic-conditioncriteria), using logical operators (such as AND, OR, NOT), keywords(such as “attack”, “upstream”, “downstream”, “protocol”, “me”), andnames of components in direct form or through an adjective, or elsethrough a service relation.

For example, the predicate “upstream(person)=admin+attack=corrupt”signifies that the “corrupt” attack is authorized to pass into thecomponent if upstream there is a person having the role “admin”(administrator).

An example of generic keywords, which is merely illustrative, is givenby table IV hereinbelow. Additionally, these generic keywords should besupplemented with the sixteen values of the potential states and thetwelve values of the attacks. TABLE IV Generic Usable by keywordDesignates Meaning Rules Attacks upstream component upstream(possibility and + contagion rules) upstream component upstream (otherrules) + under alleged name downstream component downstream + mecomponent currently undergoing + processing entry component lasttraversed upstream (= + entry relation) start component firstupstream + + target component target of the attack + + finish componentfinish point of the attack + + attack attack type of an attack + +protocol protocol type of protocol + + intermediate component imposed onthe path of the + attack islicit mode indicates whether the + attack islicit or not present state presence of a component in + a stack absentState absence of a component in + a stack authentic state state of anonusurped + component usurped state state of a component + usurped byanother usurper component component which usurps + another one

The components description language makes it possible to write rules,which each comprise a variable number of predicates (Boolean logicalcondition) and possibly of actions. For each component, there are eighttypes of rules. The rules have two independent characteristics:

-   -   they may be binary (Boolean logical conditions, giving a yes/no        value) or functional (logical condition involving a routing or        contagion action); and,    -   they may be “propagation rules” (in the attack vector        components) or “absorption rules” (in the attack target        components).

In an example, five propagation rules and three absorption rules aregiven respectively by table V and by table VI hereinbelow. TABLE V ruletype role example possibility binary defines which attacks softwarecannot may pass transport a postal parcel identification binary providesfor the an attack will be upstream identification and accepted if theauthentication of the password has been upstream components previouslydivulged identification binary provides for the downstreamidentification and authentication of the downstream componentsauthorization binary defines which attacks a firewall device areauthorized to may preclude pass discovery attacks by “Ping” packetsrouting functional defines the component a router dispatches to whichthe attacks the mail messages are to be directed to the mail server

TABLE VI rule type role example possibility binary defines which attacksan office can may pass absorb a physical bomb, but not a logic bombidentification binary provides for the an attack will be upstreamidentification and accepted if the possible password has beenauthentication of the previously divulged upstream components contagionfunctional defines which states the explosion of an must be propagatedto office brings about which components the destruction of the equipmenthosted

The rules are applied as follows. Each time an attack turns up at a(current) component, the attacks/parries engine runs the mechanismillustrated by the chart of FIG. 13.

In order for an attack to be propagated by a vector component or beabsorbed by a target component, each category of binary rule must,either be empty, or comprise a rule with a positive result.

If the attack is accepted by a vector component, the latter applies thefunctional routing rules according to the mechanism illustrated by thechart of FIG. 14 a. Likewise, if the attack is accepted by the targetcomponent, the latter applies the contagion rules according to themechanism illustrated by the chart of FIG. 14 b.

The local routing and functional mechanisms will now be described. Thefunction of routing is to direct the attacks from one component to theother, with the aim of reaching the finish point or the intermediatepoints. There are two kinds of routings.

Firstly, functional routing, defined by the user via the routing rules,and which makes it possible to define a new intermediate componentbefore reaching the finish point. This component is inserted into thedownstream stack. For example, a router decides to route an email comingfrom outside to the messaging server.

Secondly, local routing, invisible to the user, the effect of which isto direct the attack to the next component of the downstream stack,according to the shortest path. A local routing table is used for thispurpose. It is recalled that this table is constructed automatically atthe end of modeling, according to the principle of searching for theshortest path. In an example, it is structured in the form of astart/finish (component) matrix.

Functional routing makes it possible to provide both for the nominaloperation of the system, and certain security functions. For example, arouter which dispatches the IP packets to a firewall device provides fora security function. This security function may be degraded in the caseof diversion, as will now be described.

The technique of diversion, fundamental in attack scenarios, may betaken into account by the device. This technique consists in modifyingthe way in which the functional routing is effected. There are threekinds of diversions, illustrated by the chart of FIG. 15.

Represented in FIG. 15 is an example of a propagation path going from aclient 151 to a server 155 through (in this order) a first router 152, afilter 153 and a second router 154.

A first diversion is a bypass diversion, symbolized by the arrow 156. Inthe example represented, the router 152 is altered so that itsdownstream component, the filter 153, is deleted.

A second diversion is an interception diversion, symbolized by thearrows 158 a and 158 b. In the example represented, the router 152 isaltered so that a downstream component 157 is added into the propagationpath. This downstream component is a hacker (usurper). In this case, theserver 155 is said to be usurped.

A third diversion is a usurping diversion, symbolized by the arrow 150.In the example represented, the router 154 is altered so that itsdownstream component, the server 155, is replaced with anotherdownstream component 159. This other downstream component is a hacker(usurper), the server 155 is said to be usurped.

A diversion may be effected by any component having a routing function,situated in the path of the attack. It is triggered by the conjunctionof three conditions:

-   -   the routing component has an “altered” state (indicating that        its routing tables are altered);    -   the finish component is “usurped” (at least in respect of        usurping and interception); and,    -   the routing component has a (or several) particular rule which        provides for diversion.

A first supplementary mechanism of the invention, consisting of themetrics of feasibility and of nondetection, will now be presented.

The aim of the metrics is to supplement the rules language, which ischiefly centered around protection by prevention. They make it possibleto rank the success or the failure of the attacks, by calculating afeasibility and nondetection coefficient, thus affording protection bydetection.

In an example, there are five metrics of which three are basic metrics,which are parametrized during modeling, and two are mishap probabilitymetrics, which are calculated during simulation.

In order to avoid getting caught up in complexity, the basic metrics areevaluated on a restricted number of levels, for example four levels.This scale of levels should be understood as a logarithmic scale, thatis to say each level involves a multiplier coefficient with respect tothe lower level. The four levels correspond for example to the values0.1%, 1%, 10%, 100%.

Two basic metrics relate to the viewpoint of the defender. These are: ametric of effectiveness of parries (resistance), and a metric ofeffectiveness of detection of attacks. These two metrics areparametrized by the user during the modeling phase, independently foreach protection rule in each component, according to a scale of valuessuch as low, average, high, absolute.

Furthermore, a basic metric relates to the viewpoint of the attacker.This is a metric of means of the attacker. This metric comprises forexample the following aspects: skill, tools, money, time. It isparametrized by the user during the simulation phase, in a global mannerfor the attacker, all means, all attacks and all targets includedtogether. The scale of values is for example: public, initiate,specialist, expert.

The metrics of probability of mishap are calculated by theattacks/parries engine during the passage through each component, thenconsolidated by the engine over the whole path, then over the wholescenario. This is a metric of probability of passage of an attack on acomponent, on the one hand, and a metric of probability of nondetectionof an attack on a component, on the other hand. Preferably, they areexpressed on the four-level scale of the basic metrics, supplementedwith the 0% level, and they are calculated according to the followingformulae:probability of passage=(means of the attacker)/(effectiveness of theprotection);probability of nondetection=(means of the attacker)/(effectiveness ofthe detection).

Table VII hereinbelow gives the calculation of the metrics calculated.TABLE VII Effectiveness of the 0.1% Low 0.1% 1.0% 10.0% 100.0% defender1.0% Average 0.0% 0.1% 1.0% 10.0% 10.0% High 0.0% 0.0% 0.1% 1.0% 100.0%Absolute 0.0% 0.0% 0.0% 0.1% Means of the attacker

Public Initiate Specialist Expert 0.1% 1.0% 10.0% 100.0%

Another supplementary mechanism of the invention, which forms part ofthe man/machine interface, will now be described.

Advantageously, the man/machine interface exhibits a so-called“multiview” functionality. This is not in itself original, since mostsoftware uses this sort of functionality. What is original, on the otherhand, is the use of views to aid the user to control complex systems, byvirtue of an association between the (software) views and the(conceptual) subsystems.

The system of “views” is an important element of the man/machineinterface, which allows the modeling of complex systems. Its principleis to decompose the system into several views, one of which alone isdisplayed on the screen in the main window, the user being able to passalternately from one view to the other. Any component may be placed in aview, in another, or in several views, as the user chooses.

The diagram of FIG. 16 shows an exemplary graphical representation of a(modeled) system according to three overlaid views. The wavy linesymbolizes an attack path passing through the three views.

There are no constraints in respect of the definition of the views, andin respect of the distributing of the components into the various viewsof a system. It is for example possible to put in place views associatedwith the various jobs of the system (geographical, computing,organizational).

Advantageously, with the help of certain simple principles, taken inisolation or in combination, the views nevertheless become an element offunctional structuring of the systems.

According to a first such principle, each view preferably represents asubsystem that is relatively autonomous and independent of the remainderof the system.

According to a second such principle, matters are preferably contrivedsuch that there are no propagation relations nor service relationsbetween two views. Only the common components shared by two viewsprovide for the function of interconnection between the views.

According to a third such principle, finally, the rules of thecomponents situated in a view should not call by name upon componentssituated in another view.

More generally, there are two ways of designing the views. Either theviews are considered to be mutually interconnected subsystems of likelevel (for example, sites interconnected via the Internet, the commoncomponent being the Internet). Or else one of the views is considered tobe a global description of the system, while the others representdetails of this or that complex component. This approach is called thehierarchical approach and will now be detailed.

The hierarchical approach is very powerful, since it makes it possibleto assemble detailed components fine-tuned previously to form verycomplex and realistic systems by assemblage, while remaining simple tovisualize.

In this approach, illustrated in the form of an example given in FIG.17, a higher view presents the global system, which contains one or morecomponents each representing a subsystem. Each lower view gives thedetail of a subsystem. In the figure, the wavy line symbolizes an attackpath passing through both views.

A component A common to the higher view and to a lower view, called a“relay component”, represents the subsystem seen from the global system,and vice versa. The relay component is the only interface between thetwo views.

The relay component provides for the leaktightness between the views,while providing for communication between them, according to a triplerole.

The relay component provides firstly for a routing relay role.Specifically, it provides for the routing of the attacks in bothdirections between the two views. For this purpose it uses all therouting criteria available in the rules language.

The relay component then provides for a service relay role.Specifically, it can have service relations, starting or ending, in thetwo views. This makes it possible to designate a component from one viewto another via indexation.

The relay component finally provides for a state contagion relay role.For this purpose, in respect of the higher view it provides for asynthetic picture of the lower view, via a contagion of the main statesrepresentative of this view.

In FIG. 18, in which the same elements as in FIGS. 1 and 2 bear the samereferences, is represented the schematic diagram of an exemplaryembodiment of a device according to the invention. This device isappropriate for the implementation of the method according to theinvention.

In this example, the device is installed in a general usage computercomprising a microprocessor 10. The man/machine interface 15 and theattacks/parries engine 16 are implemented in the form of softwaremodules, saved in a memory 17 and more particularly in a read onlymemory (ROM). They are executed by the microprocessor 10 when they areloaded into the random access memory of the computer.

To provide for the input of data values by the user, the devicecomprises a keyboard 19 b, and in general also a mouse (not represented)or the like. For the displaying of the data, in particular thedisplaying of the graphical representation of the system modeled in theform of one or more views, the device also comprises a screen. Theseelements are those which equip the computer.

Finally, the device comprises a random access memory 18, in particular aRAM memory, in which the files 11, 12, 13 or 14 may be saved.

1-44. (canceled)
 45. A method for analyzing the security of aninformation system comprising: a modelling phase, comprising on the onehand the specification of the architecture of the information systemwith a graphical representation of a set of components of the system andrelations between said components, each component being associated withat least one state initialized with a sound value, the relations betweentwo determined components comprising propagation relations able toconvey attacks, and on the other hand the specification of a set ofbehavioural rules, from the standpoint of the operation of the systemand from the standpoint of security, associated with the components ofthe system, each behavioural rule comprising one or more predicatesand/or one or more actions; and, a simulation phase, comprising thespecification and the simulation of potential attacks against theinformation system, a successful attack causing a state of a componentto pass to an unsound value.
 46. The method of claim 45, wherein, a namebeing associated with each component, one or more adjectives may also beassociated with said component, which adjectives make it possible todesignate said component without naming it.
 47. The method of claim 45,wherein determined states are associated with each component of theinformation system, each state being able to take a sound value and oneor more unsound values.
 48. The method of claim 47, wherein certain atleast of said states pertain respectively to the activity, theconfidentiality, the integrity and/or the availability of the componentwith which they are associated.
 49. The method of claim 45, wherein analleged name may be associated with any determined component, inparticular in the case where said determined component is a usurper. 50.The method of claim 45, wherein a link to another component may beassociated with any determined component, in particular in the casewhere said determined component is usurped and where said othercomponent is a usurper.
 51. The method of claim 45, wherein thepropagation relations are bidirectional relations able to convey attacksin both directions.
 52. The method of claim 45, wherein the relationsbetween any two determined components comprise service relations makingit possible to designate a component on the basis of another component.53. The method of claim 45, wherein the behavioural rules comprise rulesfor propagating attacks, these rules being for example implemented incomponents which are vectors of attacks, and rules for absorbingattacks, these rules being for example implemented in components whichare the target of attacks.
 54. The method of claim 45, wherein thebehavioural rules comprise binary rules, for example Boolean logicconditions giving a value of type yes/no, and/or functional rules, forexample logic conditions involving a routing action (for a propagationrule) or contagion action (for an absorption rule).
 55. The method ofclaim 45 comprising, at the end of the modelling phase, the constructionof a local routing table, making it possible to direct an attack from astart component to a finish component.
 56. The method of claim 55,wherein the local routing table is generated automatically according tothe principle of the shortest path between the start component and thefinish component.
 57. The method of claim 56, wherein the attackssimulation step comprises the updating of the state of a component ofthe system altered by a successful attack.
 58. The method of claim 57,wherein the simulation phase furthermore comprises the building of afile or journal of the attacks, containing the log of the changes of thestate of the components consequent upon successful attacks, inparticular to allow subsequent processing by a user.
 59. The method ofclaim 57, wherein the attacks comprise elementary attacks correspondingto unsound state values.
 60. The method of claim 57, wherein the attacksfurther comprise a special usurping attack.
 61. The method of claim 57,wherein an attack is defined, in particular, by a type of attack, a typeof protocol, and attack path elements.
 62. The method of claim 61,wherein the attack path elements comprise a start component, a finishcomponent, a target component, and as appropriate one or moreintermediate components.
 63. The method of claim 61, wherein the list ofcomponents already traversed by an attack is saved in one or moreupstream stacks.
 64. The method of claim 63, wherein the upstream stackscomprise a stack containing the exhaustive list of all the componentstraversed, designated by their real name.
 65. The method of claim 63,wherein the upstream stacks comprise a stack containing the list of onlythose components traversed which are opaque, designated by their realname or, as appropriate, by their alleged name.
 66. The method of claim61, wherein the list of destination components of an attack is saved inat least one downstream stack.
 67. The method of claim 61, wherein theattacks are defined in a language using the same words as a language inwhich the behavioural rules are defined.
 68. The method of claim 61,wherein the modelling phase and/or the simulation phase are implementedby a user by means of a man/machine interface comprising a multiviewfunctionality, wherein a graphical representation of the system ispresented to the user as several views.
 69. The method of claim 68,wherein each view represents a subsystem of the system, which isrelatively autonomous and independent of the remainder of the system.70. The method of claim 68, wherein the function of interconnectionbetween the components included in two distinct views is ensured onlyvia the common component or the common components shared by the twoviews.
 71. The method of claim 68, wherein the behavioural rules for thecomponents belonging to a view do not call by name upon componentsbelonging to another view.
 72. The method of claim 68, wherein the viewsare associated with respective subsystems, for example of like level,which are interconnected together via at least one common component. 73.The method of claim 68, wherein a higher view is associated with thesystem as a whole, whereas one or more lower views are respectivelyassociated with a determined subsystem of the system.
 74. The method ofclaim 73, wherein a determined component, common to the higher view andto a determined lower view, represents the corresponding subsystemviewed from the system as a whole, and vice versa.
 75. The method ofclaim 74, wherein said common component is the sole interface betweenthe higher view and said determined lower view.
 76. The method of claim74, wherein the modelling phase further comprises the specification ofone or more basic metrics associated respectively with the components.77. The method of claim 76, wherein the basic metrics comprise a metricof effectiveness of parries, a metric of effectiveness of detection ofattacks, and/or a metric of the means of an attacker.
 78. The method ofclaim 76, wherein the simulation phase comprises the calculation of oneor more metrics of probability of mishap.
 79. The method of claim 78,wherein the metrics of probability of mishap comprise a metric ofprobability of passage of an attack on a component.
 80. The method ofclaim 78, wherein the metric of probability of passage of an attack on acomponent is calculated according to the formula “probability ofpassage=(means of the attacker)/(effectiveness of the protection)”. 81.The method of claim 78, wherein the metrics of probability of mishapcomprise a metric of probability of nondetection of an attack on acomponent.
 82. The method of claims 81, wherein the metric ofprobability of nondetection of an attack on a component is calculatedaccording to the formula “probability of nondetection=(means of theattacker)/(effectiveness of the detection)”.
 83. A device for theimplementation of a method for analyzing the security of an informationsystem, said device comprising: a man/machine interface for theimplementation of a modelling phase comprising a modelling phase,comprising on the one hand the specification of the architecture of theinformation system with a graphical representation of a set ofcomponents of the system and relations between said components, eachcomponent being associated with at least one state initialized with asound value, the relations between two determined components comprisingpropagation relations able to convey attacks, and on the other hand thespecification of a set of behavioural rules, from the standpoint of theoperation of the system and from the standpoint of security, associatedwith the components of the system, each behavioural rule comprising oneor more predicates and/or one or more actions; and, an attacks/parriesengine for a implementation of a simulation phase comprising thespecification and the simulation of potential attacks against theinformation system, a successful attack causing a state of a componentto pass to an unsound value.
 84. The device of claim 83, wherein theman/machine interface has a functionality of multiview display of thesystem modelled.
 85. The device of claim 83, wherein the man/machineinterface is configured to display the system modelled according to acomponents/relations model.